The present invention relates to the interfaces between a host system and a peripheral device and more particularly to methods and a device for implementing multifunction peripheral devices, in particular USB multifunction peripheral devices, with a single standard peripheral device driver, (that is, without a specific peripheral device driver).
There are many USB peripheral devices, for example storage, pointing or data security devices, being able to be connected to a host system comprising an operating system and applications executed on this system.
To enable the exchange of data between a USB peripheral device and the host system, the operating system of the latter comprises one or more peripheral device drivers enabling a peripheral device to be accessed and used. In many cases, the peripheral devices can be implemented with standard peripheral device drivers, integrated into the operating system.
Nevertheless, in modern operating systems, it is generally possible for a peripheral device manufacturer to supply a peripheral device driver independently from the supplier of the operating system. In this case, the peripheral devices are, for example, delivered with a CDROM containing the corresponding driver(s).
Moreover, it is generally necessary to possess certain computer or system administration rights to be able to install a new peripheral device driver. Further, in some operating systems, the peripheral device drivers can or must be signed, that is be authenticated in a cryptographic manner by the operating system, for purposes such as security and determining correctness of the driver and its installation.
The access to the peripheral device by an application executed on the host system is realized by means of an interface called an API (acronym for Application Programming Interface) that defines the manner in which one software component can communicate with another, and in particular for this discussion, the interface to communicate with a peripheral device driver.
It is noted that a USB peripheral device may provide a certain number of services for the operating systems as well as for the applications. The USB standard defines a “class” of a USB peripheral device, this class can be considered as the definition of the interfaces between the peripheral device and the host system. Knowing the class of a USB peripheral device typically enables the host system to implement a driver for this peripheral device and enable another supplier of peripheral devices to implement a compatible peripheral device realizing analogous functions.
The USB standard defines the standard classes such as mass memories and network interfaces.
The USB standard also provides the possibility of describing a peripheral device as being composite. Such a peripheral device is generally called a composite peripheral device or multifunction peripheral device. It enables several functions to be implemented within one peripheral device, for example a mass memory function and a network interface function. Each function can execute different requests, a request being for example the writing, the reading, the encryption or the decryption of an item of data. A multifunction peripheral device can be considered as an agglomeration of several sub-peripheral devices, each defining its own class. A host system generally sees this peripheral device through several drivers: a multifunction driver that manages the agglomeration and then also typically one driver per sub-peripheral device that is per function.
The USB standard also enables a USB peripheral device to implement a class not defined by the standard. In this case, the supplier of the peripheral device must typically provide a specific driver for the peripheral device for each different operating system that the supplier wants to provide support.
For example, a cryptographic peripheral device can provide a secure storage as well as the PKCS#11 services describing certain services and cryptographic APIs. (PKCS stands for Public Key Cryptography Standard, and PKCS #11 is the PKCS Cryptographic Token Interface Standard. PKCS is a known standard utilized by the RSA Company). The peripheral device must typically then implement the mass storage class and a PKCS#11 class that is specific to it.
FIG. 1 illustrates an implementation example of such a multifunction peripheral device comprising a secure storage and offering PKCS#11 services.
The host system 100 is here connected to a peripheral device 105 comprising a secure storage and offering the PKCS#11 services 170 via a USB bus 110.
The applications 115 implementing the storage functions of the peripheral device use the file system driver 120 itself using the USB storage driver 125, that is a USB storage standard driver. The USB storage driver 125 calls a USB multifunction driver 130 using a USB bus driver 135.
In the same manner, the applications 140 implementing the PKCS#11 services call a PKCS#11 library 145 that is based on a PKCS#11 driver 150, that is a driver specific to the PKCS#11 services. Like the USB storage driver 125, the PKCS#11 driver 150 calls the USB multifunction driver 130 using the USB bus driver 135.
In the peripheral device 105, the secure storage services 155 use a USB storage driver 160 that itself calls a USB bus driver 165.
In a similar manner, the PKCS#11 services 170 of the peripheral device 105 use a PKCS#11 driver 175 that itself calls the USB bus driver 165.
However, the interfacing of the USB peripheral device with an application being executed on the host system poses several technical problems.
First of all, a given operating system only provides USB peripheral device drivers for certain classes of peripheral devices. These peripheral device classes generally correspond to the most widely used peripheral devices such as keyboards, mice and keys or USB disks.
Moreover, even if the services provided by a peripheral device are defined by a standard, the mechanisms used to implement the interface are not always defined. For example in the case of a peripheral device providing the services defined by PKCS# 11, the APIs are defined between the applications using PKCS#11 and the suppliers of PKCS#11 libraries but the interface between the library and the peripheral device is not covered by the standard, which explains why that there is no standard driver to interface the library and the peripheral device.
It can also be observed that a USB peripheral device should preferably be useable with several types of operating systems. It can also be used before or during the start up of an operating system. In this case, the peripheral device must typically be identified according to one of the classes supported by the BIOS (acronym for Basic Input Output System) so that the BIOS can access it. There are many different BIOSs and most do not implement all the protocols and classes defined by the USB consortium. In particular, some BIOSs can refuse to function with a composite peripheral device even if they might correctly support one of its classes.
For example, there are some BIOSs capable of starting on a USB disk but incapable of starting on a peripheral device identified as a composite peripheral device of which one of the classes is the disk class. However, it can be essential to start on a cryptographic peripheral device providing a secure storage. It is therefore important or advantageous that any BIOS supporting the start up on a USB disk can start on such a secure peripheral device (composite peripheral device).
It will also be observed that the installation of a peripheral device driver generally requires high administration rights in the host system. Moreover, the operating system may limit or even prohibit the installation of unsigned drivers, which implies having to sign the specific driver. This prohibition or decision for requirement is generally made at the discretion of the supplier of the host system.
Moreover, it may be necessary to supply one peripheral device driver for each version of the operating system. Because of these complexities, the development cost and effort in terms of tests and validation of the driver by the supplier of the peripheral device to provide all of the required drivers can become unacceptable and may lead a supplier to limit the breadth of support of his peripheral device to a small number of operating systems and versions.
Further, the small space required and the functionalities of certain USB peripheral devices encourage their use in “nomad” mode that is their use on a computer not belonging to the owner of the peripheral device. For example, a cryptographic peripheral device can be used in a cybercafé to enable the encryption and the signature of e-mails. In this type of use, the user of the peripheral device rarely has the possibility or sufficient rights to install a driver specific to the peripheral device on the computer or machine that he is using.